Industrial controllers are special purpose computers used for controlling industrial processes and manufacturing equipment. Under the direction of a stored program, an industrial controller examines a series of inputs, reflecting the status of the controlled process, and changes a series of outputs controlling the industrial process. The inputs and outputs may be binary, that is on or off, or analog, reading or providing a value within a continuous range.
An industrial controller differs from a conventional computer in two respects. First, unlike a conventional computer, the hardware of the industrial controller changes substantially for different applications. This reconfiguration is facilitated by assembling the industrial controller from a number of standard modules each performing a different function. Different combinations of modules are selectively linked together on a backplane or connected together by one or more communication links to customize the industrial controller to the particular process or equipment being controlled. The modules may include, for example, various processors, power supplies, communication interfaces and input and output interfaces as well as specialized controllers such as motor controllers or temperature controllers.
The second difference between industrial controllers and conventional computers is that the software run by an industrial controller is often "one of a kind", that is, unique to a single location. This follows both from the variability of the hardware and more generally from the wide range of different processes and equipment controlled by industrial controllers.
Because most industrial controller applications require the writing of original software, it is important that such software be easy to write, troubleshoot and maintain. One successful method of writing software is that of dividing the program into a series of smaller subprograms each of which may be separately written and tested.
Industrial control programs often lend themselves to subdivision along the lines drawn by the physical, controlled processes. For example, if a factory includes a conveyor belt, a punch press and two clamps for holding work to be punched, a logical division of the software may be into control routines for each of the punch, conveyor belt and clamp.
A given clamp, for example, will have inputs controlling whether it is to be advanced or retracted and output signals indicating that it has achieved those particular states. A controlling routine will detect contradictory commands and may permit the imposition of internal states such as delays to accommodate the physical operating characteristics of the clamp.
With the partitioning of a large program into subprograms, it becomes desirable to be able to re-use those subprograms in the creation of other programs either for the same or different processes. Ideally, manufacturers of particular physical equipment that is controlled could provide subprograms for controlling that equipment much in the same way that the manufacturers of computer printers now provide printer "drivers" for those printers, the drivers being short programs to permit the interface of a particular computer to that particular printer.
Nevertheless, such reuse of subprograms is not common in the industrial control field. Although portions of an industrial controller program may be copied into a new program, that portion will generally not function without further modification because its variables, as identified by variable addresses, will normally be different from the addresses of those variables in use in the new program.
Reconciling the addresses of the variables of the copied subprogram to match those of the larger incorporating program is nearly impossible, however, because it requires a sifting through of both programs to identify all variables that may be read or written to by the copied fragment. Because it is not necessarily the case that the names of the variables used in either of the programs will indicate their proper connection, the set of shared variables must be identified through their context in the program, an extremely difficult exercise.
The difficulty of this task is compounded by the fact that many languages for the programming of industrial controllers simply do not permit the generation of a list of variables cross-referenced by functional subprograms.
The problem of coordinating variables when copying subprograms into new larger programs is particularly acute in the context of industrial control programs which by their nature have many variables representing both input and output data from sensors and controllers physically connected to the controlled process or machine. A method that permitted the ready reuse of previously written subprograms in the creation of a new, larger industrial control program would be highly desirable.